Does renovate not work here?

Deploy preview for algolia-instantsearch ready!

Built with commit 7b4a053

https://deploy-preview-2689--algolia-instantsearch.netlify.com

package.json must be updated along with the lock file too for this to work well. The yarn.lock file is not read when you install/check the dependencies as a user.

i.e. it means that if you release InstantSearch.js with this package.json and I update InstantSearch.js in my project, if my local node_modules says helper 2.23.0 then it won't be updated (but the feature you rely on won't work too)

And yes might be good to know why the helper has not been updated in package.json for so long, maybe @rarkins know why. The branches are protected so there should be PRs being opened (on weekends) but that's maybe no more the case now

2.3.0 was released long time ago so should have been updated already

Update: it's expected because it will be updated only this weekend.

@vvo are you referring to algoliasearch-helper? Its current version in dependencies is ^2.23.0, and the latest on npmjs is v2.24.0, hence it is "in range" and not eligible for an upgrade.

If you want it bumped to the exact latest version every time, there's really no benefit to any end user in having the caret ^ in place in package.json, so you can remove it and see it updating regularly.

By this I mean to say: Why use ranges at all? Usually it's in case a library is "consumed" downstream and you want to give users as wide a choice of dependencies as possible, so that's why we assume you don't want it updated to the latest. Otherwise having a range but keeping it updated to the very latest release every time is effectively the same as having no range at all.

Another alternative for you is to enable lock file maintenance, this bumps lock files even if the package.json remains the same. i.e. would achieve something similar to this PR, for every single package.

@rarkins I believe if we wait this weekend, the helper will be bumped to ^2.24.0 by renovate right?

@rarkins I believe if we wait this weekend, the helper will be bumped to ^2.24.0 by renovate right?

No, that's not the behaviour actually. The logic is: "if the latest npmjs release falls within the existing range, do not update it". This is because in most cases, people use ranges because they want to keep a wide range for downstream users.

If you need it bumped to >= v2.24.0 for functional reasons (e.g. using a feature of v2.24.0 that's not supported by v2.23.0 then that's something a developer needs to do manually, because only the developer involved could know that. If instead you just think it's best practice to keep your downstream users as updated as possible (e.g. to the latest, once a week), is there any reason why not to remove the caret range and pin it?

Another option is to use tilde ~ ranges instead, then it would bump from ~2.3.0 to ~2.4.0 but not to ~2.3.1 for example.

And finally.. this "logic" I mentioned is not written in stone and I can consider a feature request if you wish to keep bumping the range ever week. I just prefer we both understand "why" things are like they are.. my philosophy is that whenever you set out solving the wrong problem, you're always going to end up with a wrong solution :)

In short: you use ranges if you don't want to overly restrict your downstream users about which (compatible) versions they should use. If you do wish to be restrictive, then a narrower range and/or pinning sounds better.

Let me know if the above is clear or any parts are unclear or disagreeable?

When we rely on such tools (like Renovate) we should go for exact dependencies.

When we don't want to upgrade just close the PR. Correct me if I'm wrong but when you close a PR Renovate will ignore the dependency until a new version is released.

@samouss yes that's right. e.g. if existing is v2.3.0 and Renovate suggests to upgrade to v2.4.0 but you close it, then Renovate will ignore v2.4.0 forever. If v2.4.1 or v2.5.0 comes out then it will then suggest it again and you have the choice to merge or ignore.

Thanks @haroen, @samouss and @vvo for picking up this and asking questions 🤘

The reasoning here is that I was unsure about the behavior of renovate (thanks @rarkins for the explanation here 😅) and I wanted to be sure that this dependency is updated correctly for Tuesday release. It contains the new insight feature.

Clearly @vvo there is an issue with the package.json 😅 I will fix that according to renovate behavior.

#teamwork

Thanks for all the details, now I am in favour of having dependencies pinned in all libraries.